feat(infrastructure): add Azure deployment foundations - #196

<!-- Use a conventional commit-style title, such as "fix(hub): retain
prototype history". -->

## Why

<!-- Explain the problem and why this change matters in a short,
plain-English paragraph. Link the issue when applicable. -->

Operators need a guided way to install and update Hub without losing
saved answers, bypassing maintenance safeguards, or guessing whether a
failed deployment completed. This PR builds on #196 and keeps the
deployment engine and terminal interface together as one runnable flow.
The reusable design gallery follows in a separate PR.

## What changes

<!-- Describe what becomes different for a first-time reader. Explain
necessary terms. Include accurate Mermaid diagrams when they clarify the
proposal, using before/after diagrams when helpful. Add screenshots for
meaningful UI changes. -->
<!-- Omit validation sections, checklists, and routine test/CI summaries
such as "CI is green" or "tests passed". Mention only known verification
gaps that affect the change, not disclaimers about drafting this
description. -->
<!-- For UI changes, prune obsolete and duplicate stories in the
affected catalogues as part of the change. Explain removed UI or
consolidated coverage where needed; see
hub/docs/storybook.md#ui-changes-and-pull-request-evidence. -->

`npm run setup:server` opens an Azure wizard with searchable target
choices, adjacent field errors, private resumable drafts, and
full-screen or accessible inline presentation. It coordinates protected
state, image publication, temporary database provisioning, and the
existing serialized release. Failed builds can retry with a corrected
npm proxy; failed Terraform steps require a fresh plan and approval.
Operational-lock recovery and Hub shutdown each require explicit safety
checks and fresh consent.

Completion restores the shell and prints the service URL, immutable
image, saved configuration, and verified Azure resource links. Local
diagnostics omit answers, credentials, command output, and consent. The
welcome retains the GitHub Replica label. HTTP readiness does not verify
authorization; optional Hub sign-in still requires manual configuration.
No authentication setup or Hub product behavior changes here.

These final synthetic examples use the real Ink presentation components
with fabricated cloud data. They are design references, not deployment,
sign-in or recovery evidence. The receipt is split into two views so all
resource links and manual sign-in guidance remain visible.

![Welcome and cloud selection — synthetic — 112 columns × 38
rows](https://github.com/user-attachments/assets/c1a491ce-448a-482e-a896-42c7c0c3c810)

![Field validation error — synthetic — 112 columns × 38
rows](https://github.com/user-attachments/assets/2ac1f67d-3aee-4ada-a7e3-158cfa028a4e)

![Guarded Hub downtime consent — synthetic — 112 columns × 44
rows](https://github.com/user-attachments/assets/077205bd-b2d8-4fb5-80df-91c1e4ce0485)

![Separate operational lock-clearing consent — synthetic — 112 columns ×
44
rows](https://github.com/user-attachments/assets/ba25a404-214e-4b41-b4a2-5545e321aab3)

![Deployment receipt and primary resources — synthetic — 112 columns ×
36
rows](https://github.com/user-attachments/assets/3141cd06-ef24-4b22-bbc2-3c4c575dc13d)

![Remaining resource links and manual sign-in guidance — synthetic — 112
columns × 28
rows](https://github.com/user-attachments/assets/e3f70cec-634f-4360-85cd-8ddbc4795315)

A live Azure deployment and recovery exercise remain unverified; local
and synthetic evidence do not establish cloud behavior.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>